-
Notifications
You must be signed in to change notification settings - Fork 590
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(sqlsmith, deterministic-test): deterministic fuzz stability #7967
Conversation
521b9af
to
a7fd394
Compare
8b44f88
to
a7fd394
Compare
14c1980
to
a67fb87
Compare
Codecov Report
@@ Coverage Diff @@
## main #7967 +/- ##
==========================================
- Coverage 71.63% 71.63% -0.01%
==========================================
Files 1132 1132
Lines 182213 182213
==========================================
- Hits 130526 130523 -3
- Misses 51687 51690 +3
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Bump, can someone help to review this? Thanks! |
src/tests/sqlsmith/src/runner.rs
Outdated
Ok(_) => tracing::info!("successfully wrote to {}", path.display()), | ||
} | ||
} | ||
|
||
/// e2e test runner for sqlsmith | ||
pub async fn run(client: &tokio_postgres::Client, testdata: &str, count: usize) { | ||
let mut rng = rand::rngs::SmallRng::from_entropy(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just came up with an idea: Can we make queries deterministic if we provide a fixed seed for this RNG?
The current from_entropy
reads from the global RNG in the simulation test. If the execution path before this point changes (likely to happen when RW code developed), the initial state of this RNG changes as well. I guess that's why queries are not stable across PRs. 👀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay let's try it first before this PR, that is simple change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made redundant by #8047? Let's observe deterministic-test fuzzing's stability for the next week or so... |
obsolete after #8068 |
Another advantage of a fixed test set is that it allows us to ignore some cases. I guess this might be very useful, because there are lots of corner cases in SQL and expressions and most of these corner cases are unlikely to happen in real-world use cases. Instead of fixing them immediately, I tend to record first and mark them as low-priority bugs. Also, if we have the ability to ignore/disable a test case temporarily, it would be much easier to enable more features in SQLSmith because it won't be blocked by fixing these bugs. You can simply create these GitHub issues and ask the assignee to re-enable these ignored case once the bug gets fixed. BTW, if you don't like to check in these random cases, we could open a separated GitHub repo to store them. BuildKite allows us to do it easily. |
Both agree what about making fuzz testing a separate pipeline, and allowing merging a PR even when it fails? |
Agree to both as well.
I think we should block PR still if fuzz testing with pre-generated queries fail. Property of pre-generated query set is that when they were generated, either: If any query fails then, it is failing from B). This should indicate a regression caused by the PR. So the PR should not be merged still. |
PTAL, ready for review @lmatz @jon-chuang @fuyufjh @wangrunji0408.
Will re-enable inserts and try this approach in a separate PR. |
} | ||
|
||
/// e2e query generator | ||
/// The goal is to generate NON-FAILING queries. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we can support ignoring cases, this seems not necessary any more. In my mind, we can generate cases regardless of success of failure, and then mark to ignore thse unsupported ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, plan to work on this in a separate PR.
I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
#7978
freeze.zip
in deterministic test environment.generate
+run_pre_generated commands
to sqlsmith.Checklist
./risedev check
(or alias,./risedev c
)Documentation
Click here for Documentation
Types of user-facing changes
Please keep the types that apply to your changes, and remove the others.
Release note